home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 November / EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso / earcd / program / misc / blitscre.lha / blitterscreen / bltscr.doc next >
Text File  |  1980-01-14  |  6KB  |  146 lines

  1.  
  2. *** BLITTERSCREEN =:) ***
  3.  
  4. ###short:
  5.  
  6. Forget copperscreens.
  7. Blitterscreens provide a CHUNKY 256-color 2x2 or even 2x1 screen,
  8. and all fullscreen! (AGA only, ECS could do byte-chunky 16colors,
  9. not supported yet). cpu overhead very small, cpu free for rendering,
  10. this method is even useful for 030!
  11.  
  12. ###distribution:
  13.  
  14. Note: This is a hardwarehack, no warranties for anything.
  15. The example executables might crash sometimes, the blitterscreen
  16. code used with smart startup-routines should be stable.
  17.  
  18. You are allowed to use the source in non-commercial software
  19. (if you charge shareware fee I don't care).
  20.  
  21. ###method:
  22.  
  23. blitter does 2 passes to get chunky buffer into the format my special
  24. screenmode needs to display (so it's not really c2p!).
  25.  
  26. For a 320x200 2x2 mode this needs only about one frame! (scrambled buffer)
  27. So this is also interesting for 50Hz fx like done on copperscreens!
  28.  
  29. you need 3 passes if chunky source is linear, i.e. not scrambled.
  30. Needs 50% more time, still beeing fantastic speed, as most gfx need
  31. more time to render, and remember, cpu is free while blitter doing
  32. conversion.
  33.  
  34. Note: Doing a 3D-mapped game on a chipmem-only A1200, you might think
  35. blitter-dma brakes cpu more than a copperscreen.
  36. BUT: rendering needs some frames, the blitter is only active for one frame,
  37. the rest of time cpu is undisturbed while copperscreens need dma each
  38. frame. The small window sizes used in copper-clones can be done beyond
  39. one frame by blitter anyway, even when using the comfortable unscrambled
  40. mode (which might speed up your floormapper). and: no more windows with
  41. limited width (looks so ugly).
  42.  
  43. Note #2: The cpu can copy to chunky buffer in longwords to chipmem,
  44. each byte beeing extended to a 2x2 pixel block by custom hardware.
  45. Imagine your A1200 was connected to a localbus-VGA. Copying to vram then
  46. would be slower (!) as you got to copy 4 bytes to get a 2x2 pixel block
  47. (VGA beeing fastmem changes nothing).
  48. So stop whining about not having a chunky screen, there is one! :)
  49.  
  50. I admit it might be not ideal for a 040, but the 040 can do
  51. realtime-1x1-c2p while copying to chipmembuffer anyway.
  52. A 030-50 also might render faster than blitterscreen convertion.
  53.  
  54. ###Programming Blitterscreen:
  55.  
  56. All subroutines needed are in bltscr.s, and bs.s shows how to use them.
  57. bs2x1.s shows 2x1 screen while bs2x2.s uses 2x2 :) The differences are
  58. different copperlist-header and different sizes of buffers
  59. (lazy me, the 2x2 buffers are as big as 2x1 ones. look into routine-
  60. headers for exact requirements, please).
  61.  
  62.  
  63. Look into bs.s at label prg: , there the part of how to do it all begins.
  64.  
  65. It's still hardwarehack, blitter stuff could be done with QBlit,
  66. but I doubt my copperlist could somehow be in harmony with OS-screens,
  67. would be a pity if cpu doing RetinkWhatever() would need longer than
  68. the whole blitter conversion. If you know how to do it with the OS
  69. (including fast double buffering!), contact me.
  70.  
  71. Feel free to make blitterscreen OS-conform on your own, and send
  72. me a copy :)
  73.  
  74. *** The steps:
  75. - set vector $6c to the handler routine. think of vbr!
  76.   timer and timer2 (.l) are incremented each frame (stuff I used in our
  77.   intro Excess/Riot :) can be used to sync with vbl.
  78.  
  79. - now do what mkbltscr: in bs.s does:
  80.   set up coplist header (in chipmem!) with similar values like in
  81.   copl: of bs.s . bs.s does this with maksimplecop: of my startupcode.
  82.   
  83.   having copied header to chipmem, a0 must point at the end (the next
  84.   free word) of copperlist. now call mk2xY which will continue storing
  85.   into copperlist at (a0)+. then move #$fffffffe to (a0)+ to finish
  86.   copperlist!! (mk2xY tells in a0 where it stopped writing into copl).
  87.  
  88. - call c2bs or sc2bs (the scrambled one). blitter is started and does
  89.   conversion parallel to cpu, you can see this testing bltbsy which
  90.   is not 0 for conversion time.
  91.   BTW number of pixels should by a multiple of 8 (conversionwise,
  92.   screenmode with fmode=3 goes 64bit wise, so multiple of 32 2x2/2x1
  93.   pixel-blocks)
  94.  
  95.   c2bs generates a blitter-job-queue for the handler. once it's generated
  96.   calling c2bs you can restart blitter faster by moving the
  97.   queue-start-adress to bltpc (defined in vltscr.s), then setting bltbsy.w
  98.   to #1, then starting handler by move.w #$8040,$dff09c (like done in bs.s)
  99.  
  100. - while blitter is now happily converting the chunky buffer cpu is free
  101.   to render another buffer. bs.s doesn't double-buffer BTW.
  102.   You got to set up 2 different blitter-queues for double-buffering if
  103.   not calling c2bs but using the faster method described above.
  104.  
  105.   SCRAMBLING: sc2bs: scrambled chunky buffer, pixels sorted that way:
  106.   pixel-number: 042615378C...
  107.  
  108.  [the words at scramble in bs.s are the offsets to get from one to
  109.   the next pixel. do not do it the way bs.s does in inner loop.
  110.   Only render columnwise (offset constant = linelen = horiz_number_of_
  111.   pixelblocks (not planepixels!) ). if you need horizontal rendering,
  112.   use unscrambled c2bs, don't be shocked by blitter needing more time,
  113.   your engine will be faster rendering unscrambled (still slower
  114.   than blitter anyway, at least for cpus below 030-50) and so the
  115.   framerate will be higher. The scrambled version is for 50Hz demos,
  116.   not for mapping games.]
  117.  
  118. - bevore returning from your program, make sure blitter is inactive
  119.   by testing bltbsy. testing blitter-active bit isn't save, there
  120.   could still be intterrupt-requests that restart blitter.
  121.  
  122. ***phew =:)
  123. I hope you all kill copperscreen out of your engines now :)
  124. They will be still useful in demos though.
  125.  
  126. I hope that little info is enough for coding blitterscreens
  127. (sorry, no time for .guide docu ;)
  128. For having a visual impression how gfx look like on that screen,
  129. watch Excess/Riot. It's the same screenmode (but blitter convertion
  130. is done different). All fx 50Hz on A1200 with fastmem, read my .sig
  131.  
  132. IMHO it looks even better than 2x2 :)
  133.  
  134. I hope it got no bugs (yuck), please tell me (but only real bugs,
  135. I know the startup code is lame :)
  136.  
  137. ----------------------------------------------------------------------------
  138.       // fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)
  139.      // A1201 HD260 =:)
  140.    \X/      ^--fastmem rules. DO YOU KNOW YOUR FAVOURITE D**M CLONE RUNS
  141.                               ABOUT DOUBLE SPEED ON YOUR STANDARD A1200
  142.                               AFTER JUST PLUGGING IN A FASTMEM EXTENSION ?
  143.   gcc, lha, D**m style games etc run about double speed. Buy just 1 meg.
  144. ----------------------------------------------------------------------------
  145.  
  146.